12/18/2005 13:29 FAX 408 982 8210 



SILICON VALLEY PATENT GR 



iaoi2 



Appl. No. 09/982,562 
Amdt dated December 18, 2005 

REMARKS/ARGUMENTS 

In a Final Office Action dated September 19, 2005, all Claims 1-24 and 26^29 were 
rejected for various reasons. Reconsideration is respectfully requested In view of this 
amendment. 

Note that this amendment is the substantive paper of a Request for Continued 
Examination (RCE) that is concurrently filed herewith. 

Claims 1-24 and 27 stand rejected under 35 USC §101 for being directed to non- 
statutory subject matter. The Examiner stated that the claim language ''raises a question 
as to whether the claim is directed merely to an abstract idea that is not tied to a 
technological art. environment or machine ..." in the bottom half of page 4, in paragraph 4 
of the Final Office Action. 

Applicants respectfully disagree. Specifically, there is no "technological arts" test 
for patentability under §101 . See Ex parte Lundaren , Appeal No, 2003-2088, Application 
08/093.516 (BPAI Opinion, Sept. 2005). Instead, under current law, an invention falls 
within the scope of §1 01 if the claimed invention transforms or reduces an article to a 
different state or thing, or if the claimed invention othenA/ise produces a useful, concrete, 
and tangible result. And Claim 1 transfonms or reduces one of the first version and the 
second version (whichever is identified as the release version) to a different stgte or thing 
by performing a build on it. In doing so, Claim 1 produces a "useful, concrete and tangible 
result". Hence Claim 1 is patentable under §101 . 

At paragraph 4 on page 2 of the Final Office Action, the Examiner stated that the 
various steps of Claims 1-24 could be done by a person as a mental step or using pencil 
and paper. Applicants do not agree with the Examiner's remarks, at least because Claim 1 
as rejected already required ^'storing in a computer memory" (emphasis added). The 
Examiner did not expjlain how a mental step of a person or pencil and paper can store 
anything in a computer memory. 

Even if a claim could be done by a person as a mental step or using pencil and 
paper, this does not ^al<e the claim non-statutory. See the following remarks quoted from 
the "Interim Guidelines for Examination of Patent Applications for Patent Subject Matter 
Eligibility" which was released in October 2005: 
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It is immaterial whether the process may be 
performed by some or all steps that are carried out by 
a human. Claims are not directed to non-statutory 
processes merely because some or all the steps 
therein can also be carried out in or with the aid of a 
human or because it may be necessary for one 
performing the processes to do some or all of the 
process steps. The inclusion in a patent of a process 
that may be performed by a person is not fatal to 
patentability. AIco Standard Corp. v. Tennessee 
Valley Authority. 808 R2d 1490. 1496. 1 USPQ2d 
1337, 1341 (Fed. Cir. 1987) (citing Diehr, 450 U.S. at 
175); see e.g. Smith & Nephew, Inc. v. Ethicon, Inc.. 
276 F.3d 1304, 61 USPQ2d 1065 (Fed. Cir, 2001) 
(method claim where all the steps are carried out by a 
human). Therefore. USPTO personnel should no 
longer rely on the human step test to determine 
whether a claimed invention is directed to statutory 
subject matter. 

In the Final Office Action, at the bottom of page 2 in paragraph 4, the Examiner also stated 
that reciting "a computer implemented method" would mal^e the claim statutory. In this 
context, the above-cited Guidelines also state: 

Whether a claim recites a machine implemented 
process is not determinative of whether that process 
claim is statutory. Such a test would recognize that an 
abstraction merely implemented on a computer is 
statutory. An example will illustrate the point. Assume 
that y = 2x + C, where x and C are positive real 
numbers, is nothing more than an abstract idea. The 
claim recites: a computer- implemented process 
comprising providing x and C defined as positive real 
numbers, multiplying x by 2 to get Z and determining 
y by addinjg C to Z, Thus, the claim is nothing more 
than an abstract idea which is machine implemented 
and such a claim is not statutory. See, e.g., Benson, 
409 U.S. 63, 175 USPQ 673 (finding machine- 
implemented method of converting binary-coded 
decimal numbers into pure binary numbers 
unpatentable). However, using the machine 
implemented test, the claim would be found to be 
statutory. The Federal Circuit held that the mere 
manipulations of abstract ideas are not patentable. 
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Schrader, 22 F,3d at 292-93. 30 USPQ2d at 1457-58. 
If a claimed process manipulates only numbers, 
abstract concepts or ideas, or signals representing 
any of the foregoing, the claim is not being applied to 
appropriate subject matter, Schrader, 22 F.3d at 294- 
95, 30 USPQ2d at 1458-59. The Federal Circuit also 
recognizes that the fact that a nonstatutory method is 
carried out on a programmed computer does not 
make the process claim statutory. Grams. 888 F,2d at 
841, 12 USPQ2d at 1829(claim 16 njled nonstatutory 
even though it was a computer-implemented 
process). 



Nonetheless, to expedite prosecution of Claim 1 over prior art, Applicants have amended 
Claim 1 by adding the phrase "computer-implemented" to the preamble. In view of all the 
above remarl^s. Applicants respectfully request the Examiner to withdraw the rejection of 
Claims 1-24 over 35 USC §101 . Claim 27 has been canceled. Therefore, all Issues 
raised by the Examiner under 35 USC §101 have been addressed. 

Claim 1 was rejected for anticipation by US Patent 6,282,709 granted to Reha. 
However, Reha does not anticipate for a number of reasons. First, Reha fails to disclose a 
process (called "staging") which requires forming an association between a version (on 
the server) and a time in future until when that version is not to be released. Dates 
associated with versions in Reha's server are release dates, which appear to be dates in 
the past, relative to a cun^ent time of update by the client. For example, at column 4, line 
41 . Reha states that the date of a version Is its "date of release". There appears to be no 
teaching, explicit or inherent, that Reha's server may hold a yet-to-be-released version, i.e. 
prior to its release date, and that such a version is associated with a future date of release. 

The Final Office Action cites to Reha's col. 10 lines 16-30 for describing a software 
update manager that perfomis an automatic periodic update, which inherently requires a 
time in future. See page 8 of the Office Action, item 1, Reha's text in column 10, lines 16- 
30 is reproduced below: 



SIUOON VALLEY 
rATZKTGROOPLLr 



Software update manager 12 includes an optional scheduler 
that allows selected software components to be scheduled 
for periodic updates. This scheduler allows for automatic, 
periodic checks for down rev software and also for software 
to be downloaded during non-peak connections times. 
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thereby making the system even more user friendly. The 
optional scheduler allows software update manager 12 to 
mn in a "quiet mode". In this mode, software update 
manager 12 starts up and connects to a software update 
sender 14, performs a software cclmponent verification and 
logs the results of the verification This log file will be read 
the next time the user runs software update manager 12 or 
displays an icon to the user, via GU1 16, to indicate that 
there are pending software component files that may require 
updating. The user can then decide to update any 
component files. 

As seen from the above text, Reha at most discloses a schedule for a user's computer 
(which contains the software update manager) to check if any files within the user's 
computer may need to be updated. On such a schedule, each client checks for existence 
of versions on the server that have been most recently released (after that client's last 
update). Hence, one client's schedule is not associated with any dates in the server itself, 
i.e. release dates of versions. There is no indication whatsoever by Reha that a future 
date inherent in a client's schedule is to be used as the release date of a version. 

Second, Reha fails to show that at a current time, when a version stored on the 
server, at that cun^ent time the version is not to be released until a future date for release. 
Reha's method appears to make the version available for download whenever it is on the 
server, at least because from among several clients, any one client can check as soon as 
the version is placed on the server. Reha explicitly states that whichever most recent 
version is currently present is identified for download, in column 3 line 65 to column 4 line 
7 - which is cited in item 3) on page 8 of the Final Office Action, Reha's text in column 3 
line 65 to column 4 line 7 is reproduced below (emphasis added): 

Software component definition file 20 contains a list of 
software component files that are currently the most recent 
versions of the various software components. In the 
exemplary embodiment, the software component definition 
file 20 also contains the history of the various software 
components. For example, the software component 
definition file 20 may contain the name and latest version 
number of a particular vendor's display driver software, as 
well as version numbers and dates of previous versions of 
the display driver software. 
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Suppose Reha's "currently the most recent version" methodology is applied to an 
illustration that is shown In FIG. 3 of the cuaent patent application. It can be seen from 
FIG. 3 that at cun^ent time 240, Reha's method identifies versions 23B. 26B and 25D as 
release versions rf currently these are the most recent versions existing on the server. 

In contrast, as described in the specification of the cunrent application at page 10 
line 19 to page 11 fine 2, when using the method of Claim 1 versions 23A, 26A and 25A 
(FIG. 3) are identified as release versions using associations between versions and 
corresponding times when the versions are to be released. This identification happens 
because versions 23B, 268 and 25D are not to be released until the release date 248, 
which is yet to occur relative to current time 24C. Reha fails to disclose or suggest any 
future times for release associated with versions to be released on the server. 

Third, if a date when a version is placed in Reha's server (i.e. Reha's release date) 
is replaced by a future date (of an update schedule in one of the clients), Reha's method 
will no longer identify the most recent versions, as shown in the example discussed above. 
Specifically, referring to FIG. 3 of the current application, although 238, 268 and 25D are 
the most recently modified versions (relative to current time 240), they will no longer be 
Identified. Hence, combining Reha's teachings in column 10 with Reha's teachings in 
column 4 will no longer identify "cun^ently the most recent version". Therefore, such a 
combination teaches away from the explicit statement made by Reha (see above-quoted 
text from column 3 line 65 to column 4 line 7 in Reha's patent). 

Fourth, there is no indication by Reha, as to which client's schedule (if any, from 
among multiple clients that check the server for updates) Is to be selected when making a 
future time's association with the version being placed on the server. Moreover, there is 
no indication by Reha that the release date is further "selected", to be one of the future 
dates in the selected client schedule. The Final Office Action does not address a 
corresponding limitation in Claim 1 . Note that Claim 1 broadly covers both manual 
selection and automatic selection of a time for release, as described in the specification, at 
page 7 lines 14-15 and 21-22. Note further that Claim I's second time 
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In view of the above explanations, Applicants respectfully request the Examiner to 
withdraw the anticipation rejection of Claim 1 over Reha's patent. Claims 2-24 are 
believed to be patentable for one or more reasons of the type discussed above. 

Claim 1 is amended to remove the limitation of periodicity on the plurality of times 
because this limitation does not distinguish over Reha's schedule which is also periodic. 
Therefore, Claim 1 as now recited covers use of a plurality of times in future that are 
aperiodic. For support, see page 6, lines 1 7-1 8 of the specification. The periodic limitation 
has been moved to new Claim 30 which depends from Claim 1 and hence nanrovvs the 
scope in Claim 1 . 

Although Claims 2-6. 10-14, 16, 21-24 and 26, 27 and 29 were rejected for 
anticipation, Applicants re-iterate that explicit limitations in these claims are not disclosed 
by Reha. for example, "database" in Claim 5 and "milestone time" in Claim 13. In item 4) 
in page 8, the Final Office Action stated that such claim limitations are found elsewhere in 
Reha's patent, e-g. column 10 lines 16-30 which has been reproduced above (on pages 
1 0 and 1 1 in the cunrent Amendment). Nothing in this text quoted from Reha's column 
10 explicitly nor implicitly indicates a •'database" or a "milestone time." The citation to 
Reha's column 10 completely fails to support an anticipation rejection of Claims 5 and 13. 

Claim 4 was rejected in the Final Office Action (in the middle of page 4 thereof) as 
being anticipated by Reha's column 4 lines 35-42 and lines 49-58 which are reproduced 
I below: 

A -What's New" text file is then defined at step 202 for each 
of the software components listed in step 200. In the 
exemplary embodiment, the What's New text file describes 
the history of the particular software component. For 
example, this file may include information regarding all the 
previous versions of the particular component including 
version number and date of release. ... 

This step includes identifying the OEM's product version for 
the latest release of each particular software component. At 
step 208, the version checking method for the software 
component files is defined. This step Includes defining the 
number of files to be version checked, the version checking 
method and version checking method parameters. 
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For example, the version checking method can include any 
of the following: 1) checl< local file(s) size and time and date 
stamp; 2) check version resource embedded in the file; 

As seen from the above text. Reha's text in column 4 at most discloses dates of release, 
which are dates in the past as noted above, because Reha's method is for assisting a user 
to download software that has been released. 

There is no indication by Reha, at least not in column 4 lines 35-42 and lines 49-58, 
that anything is done when a first time in future, which is associated with a given version, 
passes. There is certainly no indication that when this happens, a new association is to be 
automatically stored between that given version and another time. 

The activity covered by Claim 4 is best illustrated with an example, assuming 
current time is Monday, and a version is associated with this upcoming Wednesday 
midnight as the time in future for release of the version. In this example, when the current 
time does becomes this Wednesday midnight, then the version is automatically associated 
with the next Wednesday midnight as the third time that Is to occur immediately thereafter, 
assuming periodicity of a week. For support, see the specification at page 15 line 30 to 
page 16 line 8, No automatic propagation of a version, from one release time to another 
release time, is disclosed or suggested in the above-quoted text from column 4 in Reha's 
patent. 

Regarding the rejection of Claim 1 1 at the bottom of page 4 of the Final Office 
Action, Applicants respectfully submit that there is no mention whatsoever (neither implicit 
nor inherent) by Reha about storing two different types of times for a given version of a 
component, one of which is a current time, and another of which is future time. The Final 
Office Action's citation to column 3 lines 55-67, column 4 lines 35-42, lines 49-58, col. 5 
lines 4-10 and lines 57-67 does not disclose the association of a version with two times. 

Claims 21 , 22. 23 and 24 were all rejected in the bottom half of page 5 of the Final 
Office Action, based on the following citations to Reha's patent: (col. 3 lines 55-67, col. 4 
lines 3S42, lines 49-58, col. 5 lines 4-10, lines 57-67). As noted above. Reha fails to 
disclose or suggest that a future time is associated with a component version for release. 
Therefore, Reha falls; to disclose or suggest that two different versions can be identified as 
the release version, depending on the current time. For example, a first version is 
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identrfied if the current time is between the first time and the second time, and a second 
version may be identified if the cunrent time is after the second time (in the event that the 
second time is after the first time). As noted above, Reha's client update method identifies 
a second version as soon as the second version is present in the server, because the 
second version is the most recent version. 

Also as noted above, Reha fails to disclose or suggest that there is any time 
dependence in associating his date of release with the version being released. In contrast 
Claim 23 requires that a second association identifying a second time is stored prior to 
occurrence of the second time, and Claim 24 requires that subsequent to occurrence of 
the second time storing of the second association is performed as an exception. 

Although Reha discloses manual approval by a user, Reha's method solicits 
approval from the user for updating of software in the client. There is no motivation or 
suggestion by Reha that such a manual approval feature in the client should be 
implemented in a server. There is no indication by Reha for an exception depending on 
whether the release time of a version occurs before or after the cun-ent time. 

Regarding dependent claims 6, 9. 17-20, Applicants first note that these claims are 
already patentable by virtue of patentability of Claim 1 from which they all depend. In view 
of patentability of these claims, there is no need for Applicant to traverse remarks in an 
office action specific to these claims, because the remarks are rendered moot by 
patentability of Claim 1 (and therefore all its dependent claims). To expedite prosecution. 
Applicants now address the statement at the top of page 9 of the Final Office Action - 
namely that "Applicant failed to point out the enrors in the motivation statements". 

In the Amendment (of July 3. 2005). Applicants did not make a general allegation 
that these dependent claims define a patentable invention, i.e. without reference to the 
assertion of Official Notice. If Applicants did not refer to the Official Notice, then as per 
MPEP the attempted traversal may be inadequate. However, in the Amendment (of July 3, 
2005), Applicants made explicit reference to the Official Notices. Specifically, in the 
bottom half of page 13 of the Amendment dated July 3, 2005 Applicants stated that there 
was no prior art citation for motivations to add various features (as recited in Applicants' 
claims) to Reha's invention. In that Amendment (of July 3, 2005), Applicants further 
requested evidence for each Official Notice. 



Page 16 of 19 

PAGE 19/22 * RCVD AT 12/18/2005 3:17:41 PM [Eastern Standard TimeJ * SVR:USPTO-EFXRF^/24 • DNIS:2738300 * CSID:408 982 8210 * DURATION (mm-ss):09-40 



12/18/2005 13:33 FAX 408 982 8210 



SILICON VALLEY PATENT GR 



@020 



SILICON VAIXBV 
rATONT OKOGP 

23SO Mitskm CaUefa Btw 

Sun Cfatv CA «50M 
(408>9S1-9200 
PAX (408) »n4ZI0 



Appl-No. 09/982,562 

Amdt dated December 18, 2005 



Hence the Amendment (of July 3, 2005) made a bona fide attempt to advance 
prosecution of the application. Applicants respectfully note that the errors In the Official 
Notices and motivation statements were identified as follows: the statements were not 
supported by any factual evidence whatsoever. In view of these prior remarks in the 
Amendment (of July 3, 2005), Applicants believe they did adequately traverse the Official 
Notices as well as motivation statements. Hence, Applicants hereby state that no 
admissions have been made. In the unlikely event that any admission appears to have 
been made, such admission is hereby withdrawn and Applicants hereby respectfully 
traverse each of Official Notices (for lack of evidence) and motivation statements (also for 
lack evidence), with further traversal in detail in the following paragraphs. 

The Official Notice and motivation statements are not only unsupported, they 
appear to be inconsistent with Reha's patent. Specifically, in rejecting Claims 6 and 17 in 
the middle of page 6, the Final Office Action stated "storing/receiving an identity of a 
person responsible for development of software was well known in the art. ... obvious to 
incorporate the teaching ... into Reha because it provides a complete record of software 
development history that can be made available for later use, such as modification or 
consultation purpose." 

Reha teaches the opposite by slating that his users do not have to know the current 
version of the software running on their computers (column 10 lines 41-44). Without 
knowing the cunrent version, Reha's users are not expected to communicate with the 
developer, because the developer Is unlikely to be helpful without knowing which version is 
njnning. Note that Reha's method Is also used by in-house users for testing purposes 
(see column 10 lines 7-15). and yet Reha does not state that the Identity of a person 
responsible for development of software is stored for display to such in-house users. 
Therefore, a skilled artisan may infer that some other mechanism is used when in-house 
users communicate with the developers. 

Claim 9 was rejected in the bottom half of page 6 of the Final Office Action for 
reasons similar to those discussed above, because the same motivation is provided I.e. 
"modification or consultation purpose" which has been discussed above. Therefore, no 
further response is needed from Applicants, 
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Moreover, in rejecting Claims 18. 19 and 20, the Final Office Action stated at the 
bottom of page 6 and top of page 7 that "selecting a convenient time to comparing 
versions of software was well known in the art ... obvious to Incorporate the teaching ... 
into Reha because one would want to perfomri this function at a convenient time." These 
statements by the Examiner are inconsistent with Reha's method for updating a user's 
computer "during non-peak connections times" (column 1 0, lines 20-21 ), Specifically, as is 
well known to any system administrator, Tuesday, Wednesday and Thursday fall in the 
middle of a week and are nomnally considered "peak" times of a week for computer usage. 
In contrast, non-peak times (as per Reha), of a normal week occur in the weekend, i.e. 
Saturday and Sunday, and in case of long weekends may also be include Monday and/or 
Friday. Therefore, Reha's non-peak times disclosure teaches away from the times 
proposed in the Final Office Action for the rejection of Claims 18, 19 and 20. 

Claim 28 was rejected for the same reasons as Claims 1 , 3, 5, 7. See the bottom of 
page 5 of the Final Office Action. However Reha fails to disclose or suggest the use of 
future times as noted above. Specifically. Reha's memory holds a version and a date of 
release, which is typically a current time when the version is placed on the server and 
made available for release. Hence Reha fails to disclose or suggest Claim 28's memory 
holding a version of a component and a time in future. 

Also as noted above, Reha discloses using the most recent version of a component, 
regardless of periodicity with which client computers check for updates. Hence, Reha also 
fails to disclose or suggest the means for detemninlng a time most recent in the past that is 
separated by a common period from a next upcoming time among a series of future times. 
Reha may at most disclose a comparison means for comparing each version's release 
time with the cunrent time. There is no suggestion by Reha for a means to compare the 
release time associated with a version with the time identified by the determining means 
and in case of a match, to supply that version as the release version. 

Hence, Applicants respectfully request the Examiner to withdraw the prior art 
rejection of Claim 28 over Reha's patent. Claim 29 depends fn^m Claim 28 and Is 
therefore believed to be patentable for one or more reasons discussed above for Claim 28 

New Claims 30-37 are added herewith. Claims 30 and 31 are believed to be 
patentable by virtue of their dependence on their respective independent claims. 



Page 18 of 19 

PAGE 21/22 * RCVD AT 12/18/2005 3:17:41 PM [Eastern Standard Time] * SVR:USPTO-EFXRF^/24 * DNIS:2738300 • CSID:408 982 8210 * DURATION (mm-ss):09-40 



.12/18/2005 13:34 FAI 408 982 8210 



SILICON VALLEY PATENT GR 



@022 



1 Appl.No. 09/982,562 
Amdt dated December 18, 2005 

Moreover, Claims 32-37 are supported throughout the originally-filed specification. For 
example, see FIG. 3 and the related description of: computers 21 A-21 P covered by the 
claimed "first computers", computer 20 covered by the claimed "second computer" as 
recited in Claim 32, Also, see FIG. 4 and the related description in the specification at 
page 13, lines 7-15 for support of Claims 36 and 37. 

Accoixlingly, Applicants respectfully request allowance of all pending claims. 
Moreover, Applicants hereby respectfully request the Examiner to call the undersigned at 
(408) 982-8203 to schedule an Examiner Interview prior to issuance of the next Office 
Action. 
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